In a typical client/server environment, a client engages a server with a request for service or information. The server responds to the request and returns information to the client. This interaction is referred to as a pull, since the client is effectively pulling information from the server. A good example of a typical pull is searching a search engine on the Internet. In this example, the client transmits a search string to the server, which responds with a list of matching elements.
Another client/server interaction involves the server transmitting information to the client without explicit instruction from the client to do so. This interaction is referred to as a push, since the server is effectively pushing information to the client. A good example of a typical push is the frequent transmission of a stock quote. The server runs software that is configured to record the stock quote at predetermined intervals and automatically transmit updates to the client. Accordingly, even though the client is not requesting the information at these intervals, the information is transmitted from the server.
For wireless networks, the current industry standard for the delivery of a push service is a Wireless Access Protocol (WAP) Push. Referring to FIG. 1, the architecture for performing a WAP Push is shown generally by numeral 100. The architecture 100 includes a Push Initiator (PI) 102, a Push Proxy Gateway (PPG) 104 and a mobile station 106. The Push Initiator 102 is typically an application running on a server in a network. The Push Initiator 102 and the PPG 104 communicate across a link 108 using a Push Access Protocol. The PPG 104, in turn, communicates with the mobile station 106 via a link 110 using a Push Over the Air Protocol.
However, in a case where an active bearer (i.e. an active network used to carry the messages of a transport-layer protocol between devices) is not available for the delivery of a Push via General Packet Radio Service (GPRS), a procedure is defined to initiate a Packet Data Protocol (PDP) Context, thus making an active bearer available. In accordance with the WAP Push specification, WAP-250-PushArchOverview-20010703-a, Version 03-Jul.-2001, the PPG 104 sends a Session Initiation Request (SIR) to a Session Initiation Application (SIA).
The SIA is an application that resides on the mobile station 106 and has been specified for the purpose for receiving and responding to SIR messages. Once the SIA receives the SIR from the PPG 104, it responds by activating an appropriate bearer and contacts the desired PPG 104 to establish the push session. The PPG 104 can then push the desired information to the mobile station 106.
Typically, the SIR is transmitted to the SIA using connectionless push, via Short Message Service (SMS). Referring to FIG. 2, a sample SMS architecture is illustrated generally by numeral 200. A SMS Centre (SMSC) 202 is coupled to the PPG 104 for receiving the SIR. The SMSC 202 is further coupled with a home location register (HLR) 204 via a signal transfer point (STP) 206. The STP 206 is further coupled to the mobile stations 106 via an over the air network 208.
The PPG 104 transmits the SIR to the SMSC 202. The SMSC 202, which acts as a store and forward system, stores the SIR. The SMSC 202 sends a SMS Request to the HLR 204 for locating the corresponding mobile station 106 to which the SIR is to be sent. The HLR 204 responds to the SMS Request with the mobile station's status.
If the mobile station's status is inactive, the SMSC 202 will wait for a predefined period of time. Once the mobile station 106 becomes active, the HLR 204 sends a SMS Notification to the SMSC 202. If the SMSC has not received the SMS Notification before the predefined amount of time has expired, the SMSC 202 will try to retransmit the SMS Request.
If the mobile station's status is active, the HLR 204 transmits the location of the mobile station 106 to the SMSC 202, which transfers the message to the mobile station 106. Once the message is delivered, the mobile station 106 responds with a verification that the message was received and the SMSC 202 does not attempt to send the SIR again. Once the SIA receives the SIR, a PDP context is established with the PPG 104 and the push can occur.
However, although conveying the SIR via SMS provides persistence, it also introduces a number of limitations. As previously described, SMS is a store and forward system which introduces delays into the delivery of the SIR message.
Further, a well know race condition can occur between the SMSC 202 and the HLR 204, which causes the SIR to be held pending at the SMSC for extended periods of time. This situation frequently occurs when the user is roaming and manifests itself, for example, as a bunching of SMS messages. A backlog of messages is delivered after the HLR and visitor location register (VLR) have been updated, typically when the user attempts to make or receive a phone call.
Yet further, delivery of the SIR via SMS is not perfectly reliable and, due to the store and forward nature of the system, the originator of the message will not discover that the message has not been delivered until the validity period for the SMS message expires, which can be significant.
Accordingly, it is an object of the present invention to obviate or mitigate at least some of the above mentioned disadvantages.